Amiga Plus 1995 #2

home *** CD-ROM | disk | FTP | other *** search

/ Amiga Plus 1995 #2 / Amiga Plus CD - 1995 - No. 2.iso / internet / faq / englisch / rec.games.design < prev next >

Wrap

Text File | 1995-04-11 | 25.9 KB | 640 lines

Archive-name: games/design-FAQ Last Updated: Feb. 21, 1994 Version: 1.54 REC.GAMES.DESIGN list of Frequently Asked Questions (FAQs). This list is posted monthly to rec.games.design, rec.answers, and news.answers. The list is maintained by Travis Casey. Any ideas for changes, additions, or corrections are exceedingly welcome, and should be directed to: casey@cs.fsu.edu Please put "rgd FAQ" or something similar in your subject line, as this is not the only FAQ I maintain. --------------------------------------------------------------------- TABLE OF CONTENTS (New or changed items are marked with an * ). ----------------- Section 1 -- General Questions 1. What is the purpose of this group? 2. I'm writing a computer game in the BOGUS language, and I need help! 3. Is this group just for RPG's? 4. What is proper etiquette for this group? 5. Are there any books on game design available? * 6. Where can I find info about games on the net? 7. What is the address of company X? 8. I'm worried about protecting my ideas. How do I copyright my game? 9. Do you have any advice for a beginning game designer? Section 2 -- RPG Questions 1. What is net.rpg's status? 2. What is net.rpg, for that matter? 3. What is FUDGE? 4. I'm trying to design an RPG. What advice do you have? Section 3 -- Computer Games 1. What is FRUA? 2. What's the best language to write a game in? Section 4 -- Wargames and Boardgames 1. I'd like to get a wargame published. What should I do? * 2. FTP-able games. --------------------------------------------------------------------- Section 1 -- General Questions 1. What is the purpose of this group? This group is meant for discussion of the design aspects of games--board games, computer games, role-playing games (RPG's), card games, or any other sort of game. This is the place to post ideas for games, thoughts about systems, questions about how something should work in a game, or anything else about designing games. 2. I'm writing a computer game in the BOGUS language, and I need help! This isn't a good place to look for help with computer languages. The main focus of this group is on *design*, not *implementation*. Try the *.lang.* and *.programmer groups first, especially rec.games.programmer. 3. Is this group just for RPG's? No. As mentioned above, all sorts of games can be discussed here. 4. What is proper etiquette for this group? It's basically the same as for any other group: use informative subject lines, if you're posting about a specific thing, include what it is in the Subject: field (e.g. "FUDGE:" at the start of a Subject line for an article discussing the FUDGE game; see below) Don't get mad if someone doesn't like your pet idea: listen to them and try to answer their points. Remember, the purpose of this group is for us to discuss our ideas and improve upon them. Some of the things that shouldn't go here include announcements that you've made a new game (unless you're posting it up for review), questions about what a specific rule in a specific game is supposed to mean, announcements of things that don't relate to designing games (e.g., role-playing BBS's, FTP sites for games, etc.), and anything else that doesn't relate to game DESIGN. 5. Are there any books on game design available? Some books that may be of assistance are: Crawford, Christopher; _The Art of Computer Game Design_ Osborne/McGraw-Hill. No longer in print, but available by writing the author c/o Osborne/McGraw-Hill. Dunnigan, James; _The Complete Wargame Handbook_ William Morrow and Co., ISBN 0-688-10368-5 Dupuy, T. N.; _Numbers, Predictions, and War_ Hero Books, ISBN 0-915979-06-3 Levy, David. _Computer Gamesmanship_ Simon & Schuster. ISBN 0-67149-532-1 Focuses on chess, checkers, and poker algorithms. Peek, Stephen; _Game Plan: The Game Inventor's Handbook_ Betterway Publications, ISBN 1-55870-315-2 Perla, Peter; _The Art of Wargaming_ Nav. Inst. Press, ISBN 0-87021-050-5 Prados, John; _Pentagon Games_ Schuessler, Nick and Steve Jackson; _Game Design: Volume One: Theory and Practice_. Steve Jackson Games. No longer in print, no further volumes were produced. Schmittberger, R. Wayne; _New Rules for Classic Games_ Strategy & Tactics Magazine; _Wargame Design_ SPI, ISBN 0-917852-01-X Zocchi, Lou; _How to Sell Your Game Design_ Gamescience (GS 10404) Note that these references have been garnered from the net, and I make no guarantee as to their accuracy. 6. Where can I find info about games on the net? The best site that I currently know of is the Games Domain site on the Web. There, you can find FAQ's for plenty of games, links to WWW sites for specific games, including ones run by the companies that put out the games, FTP links for games, a link to a list of RPG companies, and much, much more. The address is: http://wcl-rs.bham.ac.uk/GamesDomain 7. What is the address of Company X? Two lists of game company addresses are kept on Usenet, as far as I know; here's the info: The "Wargame Company E-mail Addresses" list is kept by jrboeke@uci.edu. It is generally posted once a month to rec.games.board and rec.games.design. Johnathan Sari (sruge@buck.cqs.washington.edu> maintains a "Complete Role-Playing Game Companies List," with the snail mail, email, and fax/phone numbers of most RPG companies. This list is periodically posted to rec.games.frp.misc. 8. I'm worried about protecting my ideas. How do I copyright my game? Well, I've got good news for you, and bad news. First the good: If you're in the US, England, any Western European Country, Canada, or Australia, anything you write is automatically considered to by copyrighted under the terms of the Berne convention that all these countries adhere to. Now, the bad news: a copyright does NOT protect your ideas. All a copyright does is protect the _expression_ of an idea. Thus, it's perfectly legal for someone to take all the rules of, say, Advanced Dungeons & Dragons, paraphrase them, and eliminate references to Dungeon Master and a few other terms TSR has trademarked, and sell the resulting product. That said, including a copyright notice in your work does give you one benefit: it makes it easier to collect damages if someone does copy your material. If there is no copyright notice, the copier can claim "innocent infringement" (that is, "I didn't know I couldn't copy it") and get off with a slap on the wrist. In addition, you may want to look into registering your copyright. In the US, at least, this provides definite proof that you wrote your material first, and allows you to collect money from copiers beyond simple damages. To protect the ideas of a game, a patent would be necessary. In general, though, it's probably not worth the effort. To qualify for a patent, a game must include physical components beyond simple board, dice, and rules, so that it can qualify as a "machine." Thus, most games won't be eligible. In addition, obtaining a patent is a long and complicated process which will almost certainly require you to hire a patent attorney, pay his/her large fees, and pay a large (and nonrefundable!) amount of money for a patent application. In my opinion, though, you needn't worry about protecting your ideas. Chances are that if you've thought of it, someone else has as well. Thus, refusing to discuss aspects of your game in order to protect your ideas isn't likely to keep anyone else from using that idea, and will prevent you from getting feedback which might help you improve the idea. (A bit from my own experience: a few years ago, I came up with an idea for a die-rolling method for an RPG which I had never seen before and which greatly simplified the system I was making. Since then, I've encountered at least three systems which also use the same method, none of whose authors could possibly have seen my work.) In general, games do not succeed because of any single "neat idea;" in fact, innovative games are less likely to succeed because most people do not want to learn large amounts of unfamiliar material. 9. Do you have any advice for a beginning game designer? Sure. Here's my version of the 10 commandments: 1. WRITE GAMES YOU LIKE. Never put something in a game or take something out just on someone else's say-so. If you and your friends like it, chances are somebody else will too. In the same vein, don't write a game on subject X just because it's the current "hot topic." Write games on the things YOU like and hopefully your enthusiasm will come through. 2. EXPERIENCE IS THE BEST TEACHER. The best way to learn game design is to read a lot of games, play a lot of games, analyze those games, and design your own games or game extensions. Since my main experience is with RPG's, my examples will come from them, but the idea is applicable to all kinds of games. I've read tons of RPG's: somewhere over 50 last time I bothered to count. I've played most of these, and GM'ed over 30. In addition to playing and gamemastering, though, I also analyze games. What makes this game good? What's bad about it? How would I modify it to make it do this instead? What areas does it represent well? What areas does it represent poorly? Why? Having played and analyzed other games, I use this knowledge to help with my own games. For example, both Champions and DC Heroes had good results using an exponential attribute scale for superhero gaming. Thus, if I were going to design a superhero game, I would know that an exponential scale can work very well. This kind of analysis gives you a bank of "proven" concepts to work with. 3. TEST, TEST, AND TEST SOME MORE. Playtest your games. Play them as much as possible; get other people to play them, preferably without you around, and talk to them afterwards. (Having other people play the game without your presence is called blind-testing, BTW.) In addition, think about your rules. Consider hypothetical situations and work out the probabilities involved. For example, if you're making an RPG, try figuring out the percent chance an average person has of hitting a man-sized target with a bow at a range of 1 meter, 5 meters, 10 meters, 50 meters, and 100 meters. For a WWII game, examine your CRT and figure out the probability that a small infantry unit will damage a tank unit. Repeat the calculations under different conditions; different terrain, at night, etc. This will help you find places where you've made a mistake in your math or made a bad assumption. 4. LEARN YOUR BACKGROUND. If you want to write a medieval fantasy game, read medieval literature and history. Read books about magic. Read existing medieval fantasy games. Similarly for any other type of game; if you're making a game set in the Vietnam war, read official histories of the war, unofficial histories, and especially analyses of strategy and tactics. All this background is useful in several ways: for one thing, it will help you in creating realistic rules. For another, it lessens the chance that you will make a major mistake in terminology or background. And, of course, the material is often interesting in itself. If you're not interested in learning about X, why are you writing a game about it anyways? 5. FORMAL EDUCATION. Take a class in introductory probability and statistics. Try reading some on the mathematical theory of games; you probably won't find it useful, but it does provide some perspective. Polish your English (or whatever language you plan to publish your game in); games are much easier to learn when they're well-written, or at least don't have a lot of grammatical errors. If you want to do computer games and haven't already taken any programming classes, take a few. You may not learn anything about how to program, but a good class will teach you some things about how to organize a program to make maintenance and bug-finding easier. While you're at it, build up a "reference library." This is a set of games and books on whatever subject you're making your game on. This will help immensely when inspiration strikes at 3 AM and the library is closed. 6. TAKE TIME OFF. A game is like a child; when it's first born, it's parents think it's perfect. Take some time away from your game to keep from getting burnt out and to get a fresh perspective on it. Repeat this from time to time. 7. KEEP RECORDS. Make sure you have more than one copy of your game. If you're typing the rules on a computer, keep one copy on the hard drive, one on a floppy, and a printout of a fairly recent version (say, print it out once a month, or once a week if you're working really fast). You can never have too many copies, since if it's any good, friends will want copies to borrow/keep, and having all these copies will greatly reduce the chance of losing it all to a hard drive crash/lost notebook/whatever. In the same vein, keep copies of older versions as well. You may find in playtesting that your new idea isn't as good as the old one was, and what are you going to do now if you've trashed the old copy? Keep at least one copy of the last version around, in addition to the copies of the current version. 8. DON'T FORGET THE INCIDENTALS. Great rules and writing are nice, but a good visual presentation will do wonders for your sales. If you're doing it yourself, learn something about desktop publishing, and either find some ready-made illustrations (for example, in the Dover clip art stuff or US government publications) or find someone to draw a few illustrations for you. Find a printer and talk to him/her; discuss ways to do what you want as inexpensively as possible. A lower price will help sales some, and lower expenses will help your profits. 9. REMEMBER, IT'S ONLY A GAME. Don't ignore real life to work on your game. If someone doesn't like your game, don't take it personally. Don't get worried about people stealing your ideas. Remember rule #1 and have fun with what you're doing. 10. THERE IS NO NUMBER 10. :-) And, here's some extra advice from Tom Lehmann, president of Prism Games (thanks Tom!): A. Incremental innovation often works best. If everything in your game is familiar, it will feel stale. If everything is very different, it may feel strange. A single clever twist on a familar theme is good but may result in your game being viewed as a "variant"; TWO clever twists on familiar ideas makes a game feel fresh while still easily accessible. So don't try to re-invent the wheel. Instead, try to present existing ideas cleanly and simply while extending a few key concepts in new and interesting directions. B. Revise and Polish your game ideas. Testing serves not only to clean up bugs in the game system and rules presentation but also as the forum in which the game designer may discover the game that he or she *really* wanted to put forth, as opposed to the one they actually have put together. If you leave testing to the end, this discovery may not do you any good. If you test early and often with an eye towards trying to figure out just what the game really is about, you can often improve a game considerably. "Alpha" testing can be viewed as asking the questions: "Is there a game here?" and "Have I found it yet?" "Beta" testing can be viewed as asking the questions: "Is this the best way to achieve this effect?", "Is this game mechanic essential -- or can it be simplified or eliminated?" and "Are all the major game systems working together to impart the game experience I want?" "Gamma" testing asks the question: "How can I improve game balance and presentation?" Too many designers stop after Alpha (producing an intriguing but shoddy game) or go from Alpha to Gamma, skipping Beta (producing games that are ok but not great). Often it is neccessary to go beyond your immediate friends / local gaming group early on to get enough critical analysis for you to figure out what needs to be done to improve an already pretty good game. And some more from me: I've never had clear-cut "stages" of game testing when I made games; instead, I tend to do a bit of each at every stage. I rework some systems, toss out some and replace them, and improve the balance and presentation of others, all more or less simultaneously. Part of this comes from the type of the main game that I'm working on... when doing a universal RPG, you have to work on a piece at a time. The key, though, is to find whatever works best for you. Try it different ways until you find one that's comfortable, then stick with that. --------------------------------------------------------------------- Section 2 -- RPG design 1. What is net.rpg's current status? [use net.rpg: in headers] Net.rpg is basically dead. A net.rpg FAQ is kept by Magnus; it contains a summary of some of the discussion that took place about net.rpg. (Magnus can be reached at magnus@ii.ui.no) 2. What is net.rpg, for that matter? Net.rpg isn't really anything yet. The idea is to try to hammer out a free role-playing game using the gathered game design talent here on the net. There was a large amount of discussion at first, but almost no one could agree with anyone else on what net.rpg should be like. Thus, after some time, the discussion died down. The general consensus now seems to be that net.rpg is an impossible dream; you're never going to get that many game designers to agree on anything, unless you use some type of committee approach ... and we all know how good things designed by committee usually are! However, the net.rpg discussion did generate a fair amount of good ideas. 3. What is FUDGE? [use FUDGE: in headers] FUDGE is one of the products of the net.rpg discussion; not THE net.rpg, but a net.rpg. FUDGE stands for Freeform Universal Donated Gaming Engine. It's author is Steffan O'Sullivan, who semi-regularly posts a FUDGE FAQ. (sos@oz.plymouth.edu) FUDGE is available from Wild Mule Games and via FTP from ftp.csua.berkeley.edu, in /pub/fudge. Wild Mule Games can be reached via snail mail at: P.O. Box 838 Randolph, MA 02368-0838 or via e-mail at wildmule@delphi.com 4. I'm trying to design an RPG. What advice do you have? 1. Don't think you're going to make money. Chances are you won't. 2. Don't think you're going to sell it to any established RPG company; most of them don't want to dilute the market even further by releasing yet another game. 3. If you are trying to create a game for sale, don't make it too much like any established system... there are already far too may AD&D look-alikes out there. Try to come up with something different. 4. Do make something *you* like... chances are that if you like it, someone else will too. However, if you try to listen to the "experts" and follow their advice about how realistic the game should be, how long combat should take, etc. and end up with a game you don't like a lot, chances are no else will like it too much either. Besides, if you're going to spend months or years writing something, shouldn't you have fun doing it? So, what does that leave? Well, if you're doing it for your own use, or your friend's use, go right ahead. If you're trying to break into the RPG business, you'd probably do best writing articles for RPG magazines and sending them in to them. The industry is pretty close-knit, and word does get around about who does good work (and does it on time!). --------------------------------------------------------------------- Section 3 -- Computer Games 1. What is FRUA? [use FRUA: in headers] FRUA is short for Forgotten Realms Unlimited Adventures, a program from SSI for creating computer adventures like their AD&D series. FRUA is not shareware or freeware; you should be able to order it from just about any software store. There is a mailing list devoted to FRUA (address?). 2. What's the best language to write a game in? That's a complicated question. It depends on several things: your knowledge of computer languages, what kind of game you're writing, what computer you're writing it for, and what tools you have access to. My first advice would be to program it in a language you are familiar with, and the more the better. There's nothing worse than spending most of your time looking in manuals instead of writing code. Second, go with something widely used (e.g., C). The more widely used your language is, the better the chance is that you'll be able to find someone who can help you if you need it. With the preceding in mind, if you're writing a game for PC, Unix, or Macintosh platforms, I'd recommend C. It's a powerful language, good implementations exist for all three of these platforms, and there are large numbers of C programmers out there who can help you. --------------------------------------------------------------------- Section 4 -- Wargames and Boardgames 1. I'd like to get a wargame published. What should I do? Here's some advice from Kerry Anderson, quoted with his permission. ---- QUOTED TEXT BEGINS ---- From: kanderso@nofc.forestry.ca (Kerry Anderson) I've published three games through other companies. These are MARINE:2002 (Yaquinto,1980), MOONBASE CLAVIUS (Taskforce, 1982), and CLASH OF EMPIRES (Wargamer issue 58?). It's not easy and you're at the mercy of the company if they decide to publish. The first step is to write the best letter you can to these companies, giving the impression you know what you know what you're doing and that the game suits their line and that it will be a hot seller. Expect to get no answer from some, "thanks but no thanks" from most, and "yes, send us a copy to evaluate" from a few. If you get the chance to send in the game, put every effort into producing a polished, final copy. Give them the feeling that you are a professional and that you know what you are doing. Put great effort into the graphic quality of the game to catch their eye. Write and edit the rules to death and print up the final product on a laser printer. You must make the game as appealing as you can. If the game is poorly put together, they might not want to bother trying to figure it out and reject it immediately. If the game is accepted, expect the worst in the final product. Let me describe my experiences: MARINE:2002 was my first game and admittedly was poorly put together. They accepted it, but changed it inside and out. I got bumped from "game designer" to "game concept". Admittedly, it was a slick product when they finished it but it doesn't always turn out that way. MOONBASE:CLAVIUS was a polished game. I got someone to edit and type the rules. I sent it to Avalon Hill (who, by the way, rarely look at unknown designers) and it was rejected. I sent it to Taskforce who immediately accepted it. After about a year, they put it into one of their pocket games and decided to throw in a few changes like reversing the sequence of play to fight-move. It destroyed the game but what could I do now? AUGUST 1914 was left virtually intact. They even used my rules for the final text (with a couple of small changes). Regrettably, The map was abysmal and the counters hard to read. It drifted off into obscurity. As you can see, trying to sell games to other companies can be disheartening. Expect a lot of rejection. While I do have three games published, I've had several of my games rejected, such as VIMY RIDGE (for being too realistic) and THE BATTLE OF ARMAGEDDON (for not being apocalyptic enough) by XTR - both game prototypes UNPLAYED (am I bitter?). You may be better off trying to do it yourself. This is something I'm seriously thinking about now. Kerry Anderson ---- QUOTED TEXT ENDS ---- 2. FTP-able boardgames. There are a few boardgames available by FTP. Among them are: BARNARD'S STAR, by Kerry Anderson Available from sunbane.engrg.uwo.ca as /pub/postscript/bseps.zip. This is a pkzipped set of EPS files which contain all the components of the game. To use it, you'll need something which can unzip files and a postscript printer. BARNARD'S STAR is a science fiction game on an attack on an outpost on a moon in the Barnard's Star system. Units are company sized and the scale is 100 km per hex and 10 hours per turn. The game contains lots of neat SF chrome including bombardment from space, planetary defenses, jump troops, teleporation, etc. BARONS OF FYN, by Joshua Howard Available from archive.umich.edu, in directory mac/game/card. The file is a mac compressed postscript archive. Barons of Fyn is a card game, produced by Bone Games, which also has other ftp-able games. -- Travis S. Casey <casey@cs.fsu.edu> FAQ maintainer for rec.games.design <A funny quote should go here>